Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-822ext-microsoft-window-00.txt < prev next >

Wrap

Text File | 1993-06-30 | 14.5 KB | 392 lines

Network Working Group R. Weatherley Internet Draft University of Queensland July, 1993 MIME Content-Types for Microsoft Windows Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the status of this or any other Internet Draft. Distribution of this memo is unlimited. Abstract This memo registers MIME [RFC-MIME] Content-Types for a number of file formats common to the Microsoft Windows environment. The intention is to aid interoperability between mail systems, and to enumerate possible conversions at gateways. This document does not provide detailed descriptions of individual formats, since published descriptions are already available from other sources, notably [SDK4], and are, in some cases, quite complex. Introduction The majority of the file formats are defined in [SDK4] and [MREF], with additional information about the layout of certain data structures in [SDK3]. A requirement for this document was that only formats with a previously published description would be registered. This does not preclude the registration of additional Content-Types related to Microsoft Windows at some future date, or the use of experimental Content-Types beginning with "x-" in the interim. Wherever possible, user and message transfer agents should use the Weatherley DRAFT - expires 12/1/93 [Page 1] RFC DRAFT July 1993 standard Content-Types defined in [RFC-MIME], since they aid interoperability between mail systems based on Microsoft Windows and mail systems based on other environments. If the conversion of information to a standard MIME format is not desirable, the mechanisms defined in this document may be used. Where appropriate, standard MIME equivalents of the Microsoft Windows file formats are stated. General Considerations The primary consideration of this memo is interoperability with MIME systems which operate in environments where formats specific to Microsoft Windows are not native. Therefore, the set of types registered by this memo is quite small and where types defined in [RFC-MIME] are sufficient to represent Microsoft Windows data without significant loss of information, no new types are registered. The implementation cost of converting Microsoft Windows formats to standard MIME types in message composition and gateway software is considered minimal compared to having to implement support for such formats in every MIME system. Some types are designated as likely to be superceded in future versions of the central MIME RFC's and are considered a stopgap measure until types are available to which conversion is possible without loss of information. These considerations are tempered by the need to send some documents without modification, yet tagged with a suitable Content-Type. This arises from the conceptual difference between a component of a message intended to be read when the message is received, and an attachment to a message intended to be saved away by the recipient for later processing by a tool separate from the MIME system. So, for example, although it is theoretically possible to convert a Microsoft Write document (with loss) into a series of text/enriched [RFC-RICH] body parts and embedded objects, this probably wasn't the intention of the message sender. To strike a balance between these considerations, we adopt the convention that where significant loss of information may occur during conversion, or where an unmodified attachment is desired, the document can be sent as a multipart/alternative entity comprising the actual document and a standard MIME alternative. Audio data formats MIME type name: audio MIME subtype name: microsoft-wave Weatherley DRAFT - expires 12/1/93 [Page 2] RFC DRAFT July 1993 Required parameters: none Optional parameters: none Encoding considerations: Any transport encoding capable of accomodating binary data may be used. The body part may be sent as part of a multipart/alternative entity with an audio/basic entity as the first part. There can be significant loss of audio quality during conversion, hence the use of an alternative. It is expected that this type will eventually be superceded by a richer standard MIME audio type. Consult the current list of registered MIME Content- Types before implementing this type in new message composition software. Security considerations: none Published specification: The body part contains audio data conforming to the Microsoft Wave format, defined in chapter 8 of [MREF]. Image data formats No new image formats are registered by this memo. The standard MIME image/gif format is capable of representing without loss the data contained in Microsoft Windows device independent bitmaps with between 1 and 8 bits per pixel. Bitmaps with 24 bits per pixel can be represented with loss in the image/jpeg format. The loss incurred is not expected to be significant, especially for real-life images. Microsoft Windows cursors, icons, and metafiles can be converted into bitmaps and then into image/gif or image/jpeg entities. While some loss of information may occur, this is not expected to be significant. Application data formats This section describes a number of formats that are specific to programs that accompany releases of the Microsoft Windows graphical environment. It is expected that additional formats will be added to this list over time. The formats are naturally thought of as attachments rather than as message components, and there are currently no conversions without loss that can be performed to standard MIME types. MIME type name: application Weatherley DRAFT - expires 12/1/93 [Page 3] RFC DRAFT July 1993 MIME subtype name: microsoft-group Required parameters: none Optional parameters: none Encoding considerations: Any transport capable of accomodating binary data may be used. This type should be sent as part of a multipart/alternative entity with a text/plain entity as the first part, which summarises the contents of the group file for readers that cannot understand the group file directly. Security considerations: Users should be wary of installing and using group files that originated with a remote source, since they may contain arbitrary Microsoft Windows and MS-DOS command-lines, that could wreak havoc with the user's machine. User agents should at least warn the user before performing any automatic installation procedures. Published specification: The body part is a Microsoft Windows Program Manager group file. The file format is defined in chapter 5 of [SDK4]. A group file contains data that the Program Manager uses to display icons of the applications in a group, start the applications in a group, and open related documents. Note that a group file can be very machine-specific, since it incorporates screen dimensions, icon color information, and execution paths that usually only apply to the machine on which the group file originated. MIME type name: application MIME subtype name: microsoft-write Required parameters: none Optional parameters: none Encoding considerations: Any transport capable of accomodating binary data may be used. It is possible to convert a Microsoft Write document (with loss) into Weatherley DRAFT - expires 12/1/93 [Page 4] RFC DRAFT July 1993 a series of MIME body parts, typically using a mixture of the text/enriched [RFC-RICH] entities for the text portions, and other Content-Types for the embedded pictures and OLE (Object Linking and Embedding) objects. If such a conversion is done, it should appear as the first part in a multipart/alternative entity with the Microsoft Write document as the second part. In many cases Microsoft Write documents will be attachments rather than inline message components, and also typically quite large. Hence, conversion should be done on user request rather than automatically. If a Postscript version of the document is available, it may be used as one of the parts of a multipart/alternative entity, giving better output quality at the price of greater message size. Note that Microsoft Write documents under Windows 3.1 or later may contain linked OLE objects. The data for these linked objects may not be available on the recipient's machine, so care should be taken to convert all linked objects into embedded objects before transmission. This conversion can be done by either the user, the mail user agent, or the mail transfer agent. The hexadecimal values of the first two bytes of a Microsoft Write file are 32 and BE respectively if the file contains OLE objects (either linked or embedded). The values are 31 and BE otherwise. For minimal compliance the user should be prompted for confirmation if a document contains any OLE objects. Security considerations: General MIME security considerations apply to Microsoft Write documents that contain OLE objects because object data is interpreted by external programs not within the direct control of MIME message viewers. Published specification: The body part is a document for the Microsoft Write wordprocessor distributed with Microsoft Windows. The file format is defined in chapter 8 of [SDK4]. MIME type name: application MIME subtype name: microsoft-calendar Required parameters: none Optional parameters: none Weatherley DRAFT - expires 12/1/93 [Page 5] RFC DRAFT July 1993 Encoding considerations: Any transport capable of accomodating binary data may be used. This type should be sent as part of a multipart/alternative entity with a text/plain entity as the first part, which summarises the contents of the calendar file for readers that cannot understand the calendar file directly. Security considerations: none Published specification: The body part is a file for the Microsoft Windows Calendar program. The file format is defined in chapter 9 of [SDK4]. Other formats: discussion The Microsoft Windows clipboard can save its data in a special clipboard file, described in chapter 2 of [SDK4]. Clipboard data is typically present in a number of alternative formats for the same information. The clipboard file format was not assigned a Content- Type because its role in presenting multiple versions of the same data can be subsumed by the standard multipart/alternative MIME content type, and interoperability among MIME-compliant systems is increased by explicitly typing the clipboard data using MIME conventions. In a similar manner, instead of defining a Content-Type for the object linking and embedding (OLE) file format defined in [OLE], the data associated with an embedded or linked object should be extracted and tagged with an appropriate Content-Type. As in the case of clipboard formats, this increases interoperability with MIME- compliant systems not based on Microsoft Windows. There is scope to separate the OLE file header information into a separate Content-Type and send this along with the associated object data in a multipart entity, but this has not been attempted as yet because OLE objects are rarely encountered outside of container documents such as Microsoft Write documents so very little would be gained in practice. A movie file format is described in [MREF] which was not assigned a Content-Type by this document because of ongoing standardisation efforts elsewhere to develop standard video formats. Weatherley DRAFT - expires 12/1/93 [Page 6] RFC DRAFT July 1993 References [MREF] Microsoft Corporation, "Microsoft Windows Multimedia Programmer's Reference", Microsoft Press, 1991, ISBN 1-55615-389-9. [OLE] Microsoft Corporation, "Object Linking and Embedding Programmer's Reference, Version 1", Microsoft Press, 1992, ISBN 1- 55615-539-5. [RFC-MIME] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, June, 1992. [RFC-RICH] Borenstein, N., "The text/enriched MIME Content-type", Working Draft, Bellcore, April, 1993. [SDK3] Microsoft Corporation, "Microsoft Windows 3.1 Programmer's Reference. Volume 3: Messages, Structures and Macros", Microsoft Press, 1992, ISBN 1-55615-464-X. [SDK4] Microsoft Corporation, "Microsoft Windows 3.1 Programmer's Reference. Volume 4: Resources", Microsoft Press, 1992, ISBN 1- 55615-494-1. Security Considerations Security considerations were discussed above as they pertained to individual Content-Types. Acknowledgements The author wishes to thank Nathaniel Borenstein for his valuable comments during the preparation of this draft. Author's Address Rhys M. Weatherley Computer Science Department University of Queensland Queensland 4072 Australia Email: rhys@cs.uq.oz.au Phone: +61 7 365 1657 Weatherley DRAFT - expires 12/1/93 [Page 7]